The term “virtual desktop infrastructure” (VDI) refers to a system that, among other things, uses a remoting protocol to connect a client device over a network to a remote desktop running on a server system (e.g., a host). The term “remote desktop” or “desktop” refers to an instance of an operating system or application that runs remotely to the user, e.g., on the server system in a remote datacenter. One aspect of a remote desktop is its graphical user interface (GUI), which is displayed on the client device. As the remote desktop runs on the server system, the content (and hence the appearance) of its GUI may change in response various factors including input from the client device (i.e., mouse clicks) or changes caused by an application running in the remote desktop on the server system (e.g., streaming video applications). These changes in the remote desktop's appearance are transmitted by the server system as image content to the client device using the remoting protocol.
One aspect of assessing the performance of a virtual desktop deployment is understanding the quality of the end-user experience. This quality will depend on, for example, the amount of latency a user perceives as he/she is interacting with his/her desktop. Understanding this quality is particularly important in large scale (e.g., enterprise) deployments since users in these deployments typically connect to their desktops under a variety of different network conditions, and since a particular server system may host many (e.g., tens, hundreds, or more) desktops that share server resources. Both of these factors (varying network conditions and high desktop-to-server consolidation ratio) increase the likelihood that users will experience poor performance at some point during their remote desktop sessions.
When creating the virtual desktop infrastructure (VDI) deployment, a customer may first perform sizing studies to understand the infrastructure required to support a desired number of desktops running a typical workflow for the customer. The sizing analysis provides the customer with an understanding of the number of server systems required to run the desktops, the size and type of the storage hierarchy required to support the desktops, the appropriate network environment, and wide area network (WAN) accelerators required for acceptable remote access to the desktops. The sizing studies may involve running automated workloads across multiple desktops to examine the impact of these desktops on the infrastructure. The automated workloads may be static pre-defined workloads or may be customizable to represent the workflow that may be anticipated for the customer. Also, the sizing studies may vary from a range of a simple study (e.g., looking at a number of desktops that can be supported by a single processor core and then extrapolating the results) to a more elaborate test including multiple server systems running a large number of desktops.
The above sizing analysis may analyze the performance of the VDI deployment in a testing environment. This may allow the test some leeway in monitoring the user experience. For example, random events may be injected into the workflow, such as a mouse event to open up an application is injected and then the response time for a corresponding application to open may be monitored. Additionally, the test may insert certain information, such as watermarks, into windows or videos that facilitate the measuring of the remote desktop response. Such measurement techniques are described in detail in U.S. Pat. Nos. 7,831,661, 8,166,107, and 8,347,344, which are wholly incorporated herein by reference. However, when the VDI deployment moves to a live deployment, randomly injecting events or visually altering images may not be possible. For example, users will not tolerate images they are viewing to be altered or have random events injected for test purposes. Thus, known methods for measuring the user experience in a test environment cannot be used in a live deployment.
Additionally, the live VDI deployment may have a workflow that is different from the workflow used in the sizing study. For example, in the live deployment, users may perform various events, such as checking personal e-mails or watching videos from the Internet, which differ from the expected load on the live VDI deployment in an unpredictable way. Also, the VDI workloads evolve over time in a way that cannot be predicted from a sizing study, such as new applications may be introduced to the live VDI deployment, application versions may change, or workflow habits may change, which all potentially impact how each user's remote desktop loads the live VDI deployment.
Because of the above issues, customers, when sizing the live deployment, often leave “headroom” in the deployment. For example, if the deployment is determined based on the sizing study to be able to support 100 users, the customer may configure the live deployment to support only 90 users. This builds in a headroom equivalent to the workload of 10 users that may allow the live VDI deployment to handle any differences from the workload tested in the sizing study. By running the VDI infrastructure under capacity, any resource utilization spikes or any medium-term changes in workflow may be accommodated, but this also underutilizes available resources.